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ABSTRACT 

ADRPM  (Acoustic  Detection  Range  Ptediction  Model)  is  a  software 
program  that  models  the  propagation  of  acoustic  energy  through  the 
atmosphere  and  the  detectability  of  that  energy.  This  model  was 
recently  rewritten  from  a  HP-Unix  version  into  a  PC/Windows  version, 
This  paper  describes  the  software  testing  methodology  used  to  verify 
that  the  new  version  provides  the  same  results  as  the  old  version. 


History  of  ADRPM 

ADRPM  began  its  existence  in  the  1970s  as  a  simple  BASIC  program.  Table  I  shows  its 
evolution  from  ADRPM  I  to  ADRPM  VII,  and  its  evolution  through  various  platforms  and  programming 
languages.  Much  of  the  past  development  on  ADRPM  has  been  performed  by  the  BBN  Corporation.  The 
version  in  recent  use  runs  only  on  68040-based  HP-9{X)0  Unix  workstations. 


Version 

Year 

Comments 

I 

1974 

BASIC,  by  BBN  Corp. 

n 

1975 

BASIC,  BBN 

ra 

1977 

BASIC,  BBN 

IV 

1978 

BASIC,  paper  tape  support  added  by  TACOM 

V 

1980 

FORTRAN,  University  of  Dayton 

VI 

1983 

FORTRAN,  Wyle  Research,  BBN,  Prime  850  computer 

vn 

1988 

C,  BBN,  PC/DOS  version 

vn 

1993 

C,  BBN,  68040  HP-9000  Unix  version 

vn 

2000 

C,  TACOM,  PCAVindows  version 

Table  I  -  Evolution  of  ADRPM 


Capabilities  of  ADRPM 

ADRPM  has  4  primary  calculations,  given  a  certain  vehicle  signature,  environmental  conditions, 
and  detector  parameters: 

1)  Calculate  the  acoustic  detection  range  of  the  vehicle 

2)  Given  a  detection  distance,  calculate  the  acoustic  signature  level  which  may  not  be  exceeded 

3)  Given  a  distance,  show  the  vehicle’s  acoustic  signature,  independent  of  detectability 

4)  Provide  a  sensitivity  analysis  capability,  where  tihe  effect  of  sweeping  one  of  the  input 
parameters  over  a  range  can  be  analyzed. 
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Each  calculation  above  then  has  3  graphical  outputs,  a  source  spectrum,  a  signal-to-noise  spectrum,  and  an 
attenuation  spectrum.  The  results  specific  to  each  calculation  are  also  presented  separately  in  dialog  boxes, 
such  as  the  detection  range  or  allowable  signature  level  in  dB. 

A  number  of  inputs  are  required  in  order  to  accomplish  the  above  tasks,  for  the  source  these 

include; 

•  one-third-octave  band  signature  values  (10  Hz  to  10  kHz,  3 1  bands) 

•  reference  distance  (source-to-microphone) 

•  reference  height 

•  reference  temperature,  humidity,  and  flow  resistance. 

Inputs  for  the  propagation  path  are: 

•  one-third-octave  ambient  noise  spectrum 

•  temperature,  humidity,  wind,  weather  condition 

•  flow  resistivity 

•  surface  roughness 

•  barriers  (distances  and  heights) 

•  foliage  bands  (distances  and  widths) 

For  the  detector  parameters; 

•  one-third-octave  noise  floor 

•  detector  height 

•  probability  of  hit 

•  probability  of  false  alarm 

•  detector  efficiency 

•  detector  type  (human  or  ideal) 

•  detection  rule  (DPMAX  or  DPSS,  described  below) 

Only  a  single,  omnidirectional  transducer  ot  single  human  observer  is  modeled,  and  for  the  human 
detection  case,  the  lower  frequency  bound  is  40  Hz.  The  DPMAX,  or  d’^a,  detection  rule  means  a  single 
band  over  a  certain  threshold  is  the  detection  case.  The  DPSS,  or  d’s^m  rule  uses  a  sum  of  squares  of 
detectabilities  in  all  one-third-octave  bands  as  its  detection  case.  DPMAX  is  recommended  for  naive 
human  observers,  and  DPSS  for  skilled  human  observers  or  electronic  detection  systems. 

Actually,  multiple  detection  ranges  are  possible,  such  as  the  case  where  a  barrier  makes  a  vehicle 
undetectable  for  a  certain  range,  but  further  out  the  vehicle  is  again  detectable.  ADRPM  searches  for 
solutions  out  to  20  km. 

The  exact  algorithms  used  in  ADRPM  have  varied  over  the  years,  and  vary  over  the  spectral 
bands.  Details  on  the  techniques  can  be  found  in  (ref.  1).  In  any  case,  the  following  factors  are  considered 
in  the  propagation  model: 

geometric  spreading  (V,^) 

atmospheric  absorption  ("classical”  and  molecular) 
refraction  (due  to  temperature  and  wind) 
ground  impedance 
surface  roughness 
barriers  and  foliage  bands. 

A  Windows  Version  of  ADRPM 


While  ADRPM  has  been  in  continual  use  to  the  present  day,  it  has  recently  only  been  running  on 
the  Hewlett-Packard  HP-9000  Unix  workstation.  With  the  encroaching  obsolescence  and  rarity  of  this 
hardware  platform,  we  decided  to  port  the  program  over  to  the  PCAVindows  platform.  Borland  C-H- 
Builder  4.0  was  used  for  development  due  to  its  aUowing  relatively  easy  creation  of  GUI  (graphical  user 
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interface)  programs,  and  because  the  existing  ADRPM  was  written  in  C.  The  new  version  runs  under 
Windows  95,  98,  NT,  and  2000. 

Figure  I  shows  the  main  screen  of  the  HP  version  and  Figure  2  that  of  the  Windows  version  for 
comparison. 


Figure  1  -  HPAJnix  ADRPM  Main  Screen 
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Figure  2  -  PCAVindows  ADRPM  Main  Screen 

Once  this  new  software  was  completed,  the  obvious  question  was,  “Can  we  get  rid  of  the  old  HP 
hardware  now?”  Despite  many  successful  runs  with  the  default  input  data  values,  minor  variations  from 
these  default  values,  and  some  testing  with  field  test  data,  we  could  never  quite  bring  ourselves  to  shut 
down  the  HP  system  for  the  last  time  and  send  it  on  its  way. 
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Even  though  the  core  calculation  code  of  ADRPM  is  separate  from  the  GUI  (graphical  user 
interface),  there  is  still  a  certain  amount  of  data  validation,  preprocessing,  and  postprocessing  going  on  in 
the  GUI  code,  and  all  this  had  to  be  rewritten  for  the  Windows  version.  Although  ADRPM  isn’t  considered 
to  be  a  “validated”  model,  it  has  been  run  by  various  users  for  many  years  with  good  results,  and  most  of  its 
algorithms  have  been  individually  validated  with  real-world  testing.  We  needed  to  make  sure  our  new 
Windows  version  retained  the  user  confidence  level  provided  by  the  well-tested  HP-Unix  version. 

Software  Verification  Method 

We  needed  a  collection  of  input  files  (source,  propagation,  and  detector)  which  would  exercise  all 
of  the  input  variables  over  their  full  ranges,  and  in  various  combinations.  This  method  is  referred  to  in 
software  engineering  as  statistical  testing.  Unfortunately,  many  of  ADRPM’s  inputs  are  floating-point 
numbers  with  a  wide  range.  Even  if,  for  example,  20  values  are  used  for  each,  a  full  combinatoric  test 
using  every  possible  combination  of  inputs  quickly  requires  millions  of  runs.  We  settled  upon  a  testing 
method  that  exercises  all  of  the  input  variables  over  their  full  ranges,  tests  many  combinations  of  these 
variables,  but  which  does  not  require  an  impossible  number  of  runs. 

A  simple  command-line  program  written  using  about  750  lines  of  C-i-i-  code  reads  in  script  files 
and  generates  ADRPM  input  files  with  randomized  values.  Three  types  of  input  files  are  required  for  a 
unique  ADRPM  run:  source,  propagation  (weather,  torain,  and  ambient  conditions),  and  detector.  The 
generator  program  reads  in  these  script  files  and  is  capable  of  generating  all  3  types  of  ADRPM  input  file. 


#  srcrun1.txt 

#  NOTE:  order  of  items  must  match  order  of  .libsrc  file 

r 

#  will  generate  srcrun1_1 . libsrc,  srcrun1_2. libsrc _ 

r 

filename  n  srcrun1_  libsrc 
trgnam  1  tsst_source 
refdis  f  0.0  50000.0  5 
reftmp  f  -50  120  5 
refhum  f  0  100  5 
trghgt  f  C  100  5 
refflwres  f  0  40000  5 
michgt  f  0  20  5 
[adjust  b  H3  VES 
sspec  c  srclisH.txt  5 


Figure  3  -  Example  Script  File  for  Generating  Source  Input  Files 

Figure  3  shows  an  example  script  file  which  generates  source  (.libsrc)  input  files.  The  line 
“refhum  f  0  100  5”  indicates  we  want  to  generate  at  least  five  floating-point  values  for  the  refhum 
(reference  humidity)  global  variable,  each  between  0  and  100.  As  currently  implemented,  the  program  will 
use  5  values  evenly  spaced,  i.e.;  0,  25,  50,  75,  and  100.  To  satisfy  the  requirement  of  5  unique  values,  at 
least  5  .libsrc  files  will  be  generated.  If  one  of  the  other  variables  requires  a  larger  number  of  unique 
values,  then  more  .libsrc  input  files  will  be  generated.  Since  none  of  the  items  in  the  above  example  script 
file  requires  more  than  5  unique  values,  5  .libsrc  files  will  be  generated  by  this  script  file. 

The  algorithm  for  creating  a  test  ADRPM  input  file,  in  pseudocode  is: 

For  each  item  in  the  script  file. 

Do  any  unused  unique  values  still  exist? 
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if  so,  then  randomly  pick  and  write  one  of  these  unused  values  and  mark  it  as  used 
if  not,  then  randomly  pick  and  write  one  of  the  values 

The  algorithm  for  generating  a  group  of  files  is; 

Do  any  of  the  items  still  have  unused  unique  values? 
if  so,  then  generate  another  file 
if  not,  exit  the  program 

These  two  simple  algorithms  used  together  generate  a  fairly  small  number  of  input  files  where 
each  variable  is  exercised  over  its  full  range,  and  the  variables  are  well  “mixed”  with  each  other.  For  an 
ADRPM  input  variable  such  as  Wind,  which  can  be  None,  Upwind,  or  Downwind,  this  method  guarantees 
that  all  3  values  will  be  tested. 

The  next  step  is  to  perform  a  complete  series  of  tests  using  all  possible  combinations  of  the  input 
files  generated.  For  example,  our  primary  test  series  had  5  source  files,  5  propagation  files,  and  5  detector 
files,  requiring  5x5x5=125  runs.  The  nature  of  this  testing  makes  it  surprisingly  easy  to  find  out  which 
input  variable  values  or  interrelationships  cause  problems.  For  example,  perhaps  in  all  5  cases  where 
source  file  number  2  is  used  in  a  run  along  with  detector  file  number  3,  the  program  complains  about  a  bad 
surface  roughness  value  and  refuses  to  complete  the  run. 

Any  number  of  unique  spectral  data  sets  can  be  required  for  the  source  spectrum,  ambient  noise 
spectrum,  and  detector  spectrum.  We  chose  the  5  spectra  shown  in  Figure  4.  While  these  may  not  be 
entirely  realistic  for  each  item  (source/ambient/detector),  they  did  provide  a  good  mix  of  input  values  and 
results. 


(M*  J  heouency  |H*i 

Figure  4  -  Five  Unique  Input  Spectra 

Results  of  Testing 

Table  II  shows  the  results  of  our  first  large  test  series,  where  all  the  runs  were  performed  on  both 
the  PC/Windows  version  of  ADRPM  and  the  HPAJnix  version.  While  100%  agreement  between  the  two 
versions  would  have  been  a  nice  surprise,  the  results  proved  the  value  of  this  type  of  testing.  While  aU 
previous  human-operator  testing  had  produced  full  agreement,  this  more  automated  testing  brought  out 
various  problem  areas  for  us  to  work  on  before  pulling  the  plug  on  the  old  software.  The  testing  also 
showed  that  most  of  the  input  value  checking  had  been  removed  from  the  HP  version,  sometimes  allowing 
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invalid  data  sets  to  run.  An  example  of  an  invalid  data  set  is  one  where  the  RMS  (root  mean  square) 
surface  roughness  exceeds  the  source  height,  microphone  height,  or  detector  height.  The  HP  version  lets 
many  of  these  runs  slip  through,  whereas  the  PC/Windows  version  refuses  to  execute  them. 


Possible  Results  of  the  Run 

Number  of  Cases 

Results  match,  or  both  programs  indicate  invalid  inputs 

60 

Results  don’t  match 

4 

PC  version  refuses  to  run  due  to  invalid  inputs,  but  HP  version  runs 

35 

Both  versions  crash  due  to  illegal  math  operation 

25 

PC  version  crashes  due  to  illegal  math,  HP  version  runs  but  provides 

1 

questionable  results 

TOTAL 

125 

Table  II  -  Summary  of  Test  Results 

The  testing  also  provided  result  cases  that  we  knew  ADRPM  could  generate,  but  which  we  hadn’t 
seen  before  or  at  best  very  rarely.  These  included  multiple  detection  ranges  due  to  barrier  and/or  foliage 
band  effects,  and  cases  where  no  solution  could  be  found. 

Future  Developments 

A  desirable  modification  would  be  to  allow  a  weighting  function  to  be  applied  to  the  generated 
input  values,  instead  of  evenly  spacing  them  over  the  legal  range.  We  also  would  like  to  go  further  back  in 
time  and  perform  this  analysis  on  the  ancient  (1985)  DOS  version  of  ADRPM.  A  complete  rewrite  of 
ADRPM  starting  with  a  “clean  sheet  of  paper”  remains  a  possibility,  depending  upon  how  well  this  new 
version  is  received  by  the  ground  vehicle  signature  modeling  community. 

Conclusions 

This  paper  described  the  testing  procedures  used  in  comparing  a  new  version  of  an  acoustic 
detection  model  with  the  old  one.  The  testing  method  exercises  all  of  the  input  variables  over  their  full 
ranges,  but  does  not  require  an  unreasonable  number  of  runs.  The  use  of  scripts  for  specifying  the  input 
values  and  ranges  provides  flexibility.  The  testing  proved  very  beneficial,  as  problems  were  discovered 
with  both  the  new  software  and  the  old.  The  method  described  could  probably  be  used  for  testing  other 
similar  modeling  programs  requiring  large  numbers  of  input  values. 
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